[プレビュー] Amazon Q network troubleshooting と AWS FIS を組み合わせて遊んでみた #AWSreInvent

こんにちは！ AWS 事業本部コンサルティング部のたかくに（@takakuni_）です。

今回は re:Invent 2023 で 発表された Amazon Q network troubleshooting と AWS FIS を組み合わせて遊んでみようと思います。

Amazon Q network troubleshooting とは

Amazon Q network troubleshooting とは、 VPC 内で実行されるアプリケーションのネットワーク接続の問題のトラブルシューティングをお助けしてくれる機能です。 VPC Reachability Analyzer と連携して、自然言語ベースで QA 対応してくれます。 Amazon Bedrock 上に構築され、自動不正利用検知機能を実装しているため、ユーザーはセキュアな　AI 利用が可能となっています。

対応リソース

具体的には、以下のリソース間のパスを分析することができます。 VPC Lambda や ECS Task などは執筆時点ではサポートされていないため、聞き方に注意が必要です。

• Amazon EC2 instance
• Amazon RDS DB instance
• Auto Scaling group
• Elastic network interface
• Internet gateway
• NAT gateway
• Transit gateway
• Virtual private gateway
• VPC
• VPC endpoint
• VPC peering connection
• VPC subnet

制限事項

現在は、プレビュー状態でバージニアリージョンで利用可能なことに加え、以下の制限事項があります。ただし、今後、 GA に向けて機能変更が加わる可能性があるので注意です。

• 1 アカウントあたり、最大 1 日 20 件まで質問可能
  • 24 時間ごとにリセット
• 本機能で生成された到達可能性分析の結果は、マネジメントコンソールのチャットウィンドウでのみ利用可能
  • チャットがクリアされるか、24時間経過で到達可能性分析を含む会話は削除
• AWS マーケティングウェブサイトや公式リファレンスから Amazon Q network troubleshooting は提供されていない
  • マネジメントコンソールからアクセス

やってみた

今回は Amazon Q network troubleshooting と AWS FIS を組み合わせて遊んでみようと思います。

AWS FIS (Fault Injection Simulator) は、 フォールトインジェクション実験を実行するためのフルマネージドサービスです。 AWS 上で障害を疑似的に発生させ、システムの可用性、回復性、パフォーマンスをテストするために用いられます。

AWS FIS では、どんな障害を発生させるかを「アクション」として定義し、今回はネットワークアクションの 3 つを疑似的に発生させてみようと思います。（ Amazon Q network troubleshooting が、現在バージニアリージョンのみで利用可能であるため、後半 2 つは、若干怪しいですが試してみようと思います）

• aws:network:disrupt-connectivity
• aws:network:route-table-disrupt-cross-region-connectivity
• aws:network:transit-gateway-disrupt-cross-region-connectivity

構成図

今回の構成はこちらになります。 FIS でサポートされているアクションをベースに構成を作りました。

Network ACL の遮断

aws:network:disrupt-connectivity では、指定したサブネットの Network ACL を変更し、通信障害を発生させるアクションです。今回は以下のサブネットの Network ACL に障害を発生させてみます。

では、今回の障害が発生した場合、次の経路は疎通できますでしょうか？

もちろん、Network ACL がブロックしているため、疎通できません。図にするとわかりやすいですが、実際に発生した場合、なかなか特定するのは困難だと思います。

では質問してみます。 AWS Q for Reachability Analyzer のコンソールに 「EC2 instance i-093XXXXXXXXXXXXX5 cannot ping EC2 instance i-09fXXXXXXXXXXXXX9.」 と入力してみます。

結果として、障害発生している接続先サブネットの Network ACL の受信ルールが接続元アドレスを許可していない旨が返ってきました。（インスタンスベースで質問できるの便利ですね。）

特定リージョンで利用する IP への通信遮断

aws:network:route-table-disrupt-cross-region-connectivity では、 サブネットとリージョンの 2 つを指定します。

まず、指定したサブネットのルートテーブルに障害を発生させます。

ルートテーブルのルートに、指定したリージョンで利用している IP アドレス範囲をブラックホールにするルートが追加される内容になります。

つまり、指定したサブネットにあるリソースは 東京リージョンの IP へは到達できなくなっています。

例えばですが、以下のケースは疎通できなくなります。

sh-5.2$ aws s3 ls --region ap-northeast-1 --debug ## リージョンエンドポイントを指定
2023-12-26 07:14:11,600 - MainThread - awscli.clidriver - DEBUG - CLI version: aws-cli/2.14.5 Python/3.9.16 Linux/6.1.66-91.160.amzn2023.x86_64 source/x86_64.amzn.2023
2023-12-26 07:14:11,601 - MainThread - awscli.clidriver - DEBUG - Arguments entered to CLI: ['s3', 'ls', '--region', 'ap-northeast-1', '--debug']

## 省略 ##

host:s3.ap-northeast-1.amazonaws.com
x-amz-content-sha256:e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
x-amz-date:20231226T071411Z
x-amz-security-token:XXXXX

host;x-amz-content-sha256;x-amz-date;x-amz-security-token XXXXX
2023-12-26 07:14:11,732 - MainThread - botocore.auth - DEBUG - StringToSign:
AWS4-HMAC-SHA256
20231226T071411Z
20231226/ap-northeast-1/s3/aws4_request
eeb81c10719c0da740e4348bdbb37722eff3cf1b41605298755f39320c057c78
2023-12-26 07:14:11,732 - MainThread - botocore.auth - DEBUG - Signature:XXXXX
2023-12-26 07:14:11,732 - MainThread - botocore.endpoint - DEBUG - Sending http request: <AWSPreparedRequest stream_output=False, method=GET, url=https://s3.ap-northeast-1.amazonaws.com/, headers={'User-Agent': b'aws-cli/2.14.5 Python/3.9.16 Linux/6.1.66-91.160.amzn2023.x86_64 source/x86_64.amzn.2023 prompt/off command/s3.ls', 'X-Amz-Date': b'20231226T071411Z', 'X-Amz-Security-Token': XXXXX', 'X-Amz-Content-SHA256': b'e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855', 'Authorization': b'AWS4-HMAC-SHA256 Credential=ASIAXXXXXXXXXXXXXXXX/20231226/ap-northeast-1/s3/aws4_request, SignedHeaders=host;x-amz-content-sha256;x-amz-date;x-amz-security-token, Signature=XXXXX'}>
2023-12-26 07:14:11,732 - MainThread - botocore.httpsession - DEBUG - Certificate path: /usr/lib/python3.9/site-packages/awscli/botocore/cacert.pem
2023-12-26 07:14:11,732 - MainThread - urllib3.connectionpool - DEBUG - Starting new HTTPS connection (1): s3.ap-northeast-1.amazonaws.com:443 # ルートテーブルの宛先ルートがブラックホール

では、 Amazon Q network troubleshooting に聞いてみましょう。 「The EC2 instance i-09fXXXXXXXXXXXXX9 cannot reach s3.ap-northeast-1.amazonaws.com on port 443.」 のような、東京リージョンへの通信ができない旨を伝えましたが、惜しくもソウルリージョンで分析を始めてしまいました。

Amazon Q network troubleshooting では、続けて質問できます。下のように「ソウルじゃないよ！東京だよ！」と粘ってみましたが、質問の形式がよくないらしいです。

IP アドレスで頑張る

では、「The EC2 instance i-09fXXXXXXXXXXXXX9 cannot communicate with 35.78.9.203.」 のような、質問の仕方をしてみましょう。

※ 35.78.9.203 は、 s3.ap-northeast-1.amazonaws.com で返される IP アドレスの 1 つです。

一見、上手くいったように見えますが、分析としては間違った結果を返しています。（実機ではタイムアウトでしたが、問題なく疎通できていると返されています。）

\

「アウトバウンドヘッダー」をクリックし分析をよくみてみると、送信先アドレスが異なっていることがわかります。確かに、 0.0.0.0/5 の場合はパスする結果になりますが、欲しかったのは 35.78.9.203/32 の結果です。

なぜそんなことになっているのか

結論、今回の質問は、 Amazon Q network troubleshooting では想定されていない質問でした。

再掲になりますが、 Amazon Q network troubleshooting でサポートされているリソースは以下であり、 FQDN や IP アドレスレベルでの到達生分析はサポートされていないことがわかります。

• Amazon EC2 instance
• Amazon RDS DB instance
• Auto Scaling group
• Elastic network interface
• Internet gateway
• NAT gateway
• Transit gateway
• Virtual private gateway
• VPC
• VPC endpoint
• VPC peering connection
• VPC subnet

余談ではありますが、 VPC Reachability Analyzer の場合は、 IP アドレス をサポートしており、指定可能なリソースに若干の差異があることは認識しながら使う必要があることがわかります。

特定リージョン向けで利用する TGW Peering 接続の遮断

最後に aws:network:transit-gateway-disrupt-cross-region-connectivity はリージョンと Transit Gateway を指定します。

指定した値をもとに、 Transit Gateway でアタッチしている、 リージョン間 Peering 接続に障害を発生させるアクションになります。

以下は、バージニア北部リージョンの EC2 インスタンスから東京リージョンの EC2 インスタンスへ ping が到達できるかを聞いた結果になります。リージョンを跨いだ到達生分析は VPC Reachability Analyzer ではサポートしていないため、「I was unable to find relevant network resources in your account; please try a different question.」といった結果が返されました。

今回の検証で、 Amazon Q network troubleshooting はあくまでリージョン内の接続可能性を自然言語で分析する機能であることがわかりました。

おわりに

以上、「Amazon Q network troubleshooting と AWS FIS を組み合わせて遊んでみた」でした。

この機能が出た時、 FIS で色々してみたい！と思い、色々検証していましたが、他の人よりちょっとだけ Deep Dive できたのではないかと個人的には思います。

NW-JAWS #11 でもこの機能について軽めに登壇しました。併せてご覧いただけますと幸いです。

以上、AWS 事業本部コンサルティング部のたかくに（@takakuni_）でした！